Cream of the Crop 1/Cream of the Crop 1.iso/PROGRAM/CPPSTYLE.ARJ/STYLE.THD

Text File | 1991-08-20 | 112KB | 2,950 lines

#: 33394 S5/C++ Study Group            orig=ROOT next= 28  prev=
    09-Aug-91  20:29:41                 No: 1 Replies 4
Sb: #C++ Programming Style
Fm: Brian Richter 76437,736
To: All

Hello again.

In a completely different thread, I was talking about what would constitute
good or perhaps "accepted" C++ style, as opposed to just being correct.  I'm
sure there are many such issues that are not explicitly defined but for which
people generally come up with similar answers.  So I thought that perhaps it
would be an interesting topic for discussion.

Here's an example of what I'm talking about.  This is something that I haven't
specifically seen elsewhere, but I just started doing this way. Suppose I have
a light switch.  I can either turn the switch on or off, or I might just want
to look at the switch to examine its state.  So to examine the "toggle" state
of the switch, I tend to do it like this:

  class LightSwitch
  {
    ...
    void toggle(bool b);       // Sets state of toggle
    bool toggle();             // Returns current state of toggle
  }

As an extension to this, a neat idea might be to have the "set" function return
the previous state of the toggle; that saves a step when you want to set it and
later return it to whatever state it was previously, though it may look more
confusing in the code.  But it wouldn't look confusing if it were common
practice...

                                       Brian



#: 33398 S5/C++ Study Group            orig=PgUp next= 5   prev=
    09-Aug-91  22:09:14                 No: 2 One Reply
Sb: #33394-#C++ Programming Style
Fm: Mark Betz [GAMERS] 76605,2346
To: Brian Richter 76437,736

I don't know, Brian. On the first pass your reasons for wanting ::toggle() to
return the previous state make sense. But the more I think about it the more it
seems like muddying the waters for little gain, especially if the code is
inlined, which in this case it probably would be. I guess the bottom line is a
design question: how often will you need to set, then restore, the state of the
lightswitch?

I think the whole question of C++ style is problematic. Certain styles
perpetuate themselves. For instance, I've learned almost everything I know
about C++ (maybe 10% of what there is to know <g>) from the people here, and
the BI manuals. So whatever mix of those styles becomes familiar to me is
probably the one I'll be stuck with.


                                                       --Mark




#: 33406 S5/C++ Study Group            orig=PgUp next=     prev=
    09-Aug-91  23:36:32                 No: 3 One Reply
Sb: #33398-C++ Programming Style
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Mark Betz [GAMERS] 76605,2346

That toggle could be incline and return a value should not inherently disturb
anything.




#: 33436 S5/C++ Study Group            orig=PgUp next=     prev=
    10-Aug-91  16:13:50                 No: 4
Sb: #33406-C++ Programming Style
Fm: Mark Betz [GAMERS] 76605,2346
To: Greg Comeau (ComeauComp) 72331,3421

I agree, Greg. But the question boils down to whether or not it's worth it
to duplicate the get-switch-state activity. That function was already
provided through a get-state method. Brian's idea was to add functionality
to the set-switch-state activity which would return the previous switch
state before toggling it. So the difference between the two methods is this:

       store_state = lightswitch.get_state();
       lightswitch.set_state(new_state);

or

       store_state = lightswitch.set_state(new_state);

My point was that this is a bit less comprehensible, and probably doesn't
gain you much of anything if the code is inlined (which it probably would be
in this simple example).

                                                      --Mark


#: 33405 S5/C++ Study Group            orig= 1   next= 8   prev= 2
    09-Aug-91  23:36:29                 No: 5 One Reply
Sb: #33394-C++ Programming Style
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736

I don't think I have any problem with your considering the return of the
previous state when setting the new one (such a thing is a common idiom) but I
don't think that I agree with that the bool one should have the same name.




#: 33424 S5/C++ Study Group            orig=PgUp next=     prev=
    10-Aug-91  14:17:16                 No: 6 One Reply
Sb: #33405-C++ Programming Style
Fm: Brian Richter 76437,736
To: Greg Comeau (ComeauComp) 72331,3421

Do you mean that there should be a "set_toggle" and a "get_toggle" or something
like that?

I think the first time I saw things return the previous state when you set a
new one was in some of the Windows API functions.  Now that I think of it, if
you return the previous value, there's another consistent way to think of these
functions.  The way I originally thought of them was as two functions that
happen to have the same name, one to set a value and one to get a value.  But
they could be thought of as two forms of one function.  This one function
always returns the current value, and has an optional argument of a new value
that you want to set.  I don't know how intuitive that would seem in an actual
program, but it seems like an interesting idea...

                                       Brian


#: 33455 S5/C++ Study Group            orig=PgUp next=     prev=
    10-Aug-91  23:15:50                 No: 7
Sb: #33424-C++ Programming Style
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736

Yes, I meant something connotative along the lines of get/set.

It is a common idion that set routines and return (pre-get) the old value. I
don't think this get'ing nature should allow them to have the same names
though.



#: 33409 S5/C++ Study Group            orig= 1   next= 26  prev= 5
    10-Aug-91  00:44:41                 No: 8 Replies 2
Sb: #33394-C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Brian Richter 76437,736

Well, first I see that you used InitialCaps in the class name, and used a
`bool' type, and formatted your code a certain way, and added comments.  that
is all style.  It could have been much different.

Here is some conventions from my stuff:

   class whatever {
      rect Area;
   public:
      const rect& area() const {return Area;}
      void area (const rect& a) { Area= a; }
      //....

that is, have access members in lower case, and private memebrs with the same
name in initial caps.  Have both test and set members with the same name.  Use
const in all the right places (many people forget this).

--John



#: 33425 S5/C++ Study Group            orig=PgUp next= 18  prev=
    10-Aug-91  14:17:23                 No: 9 Replies 2
Sb: #33409-C++ Programming Style
Fm: Brian Richter 76437,736
To: John M. Dlugosz 70007,4657

Yes, lots of those little things that one tends to take for granted are really
important elements of style.

As I look at your example I realize that my example could have used at least
one "const".  Being previously a C programmer I still tend to forget to include
"const" at times.  In fact, sometimes I'll just go through my classes and make
sure all the "const"s are where they should be.  I usually find a couple
missing.

I like the idea of private members and access functions having the same name;
it sort of links them together.  Although lately I seem to have converted over
to Hungarian notation.  Perhaps some would even say I've taken it to extremes.
In the last project I actually invented a different little Hungarian
abbreviation for every class.  And I added a couple of abbreviations for
private members, arrays, and constants (which was tricky because I ran out of
letters).  So I might have something like this:

  class LightSwitch
  {
    bool zbToggle;     // 'z' is for private member
    char zqcText[4];   // 'q' is for array
  public:
    bool toggle() const { return zbToggle; }
    void toggle(bool b) { zbToggle = b; }
  }

                                       Brian



#: 33442 S5/C++ Study Group            orig=PgUp next= 12  prev=
    10-Aug-91  19:12:31                 No: 10 One Reply
Sb: #33425-C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Brian Richter 76437,736

Once you add a missing `const' they tend to avalanche.

same name:  a while back we went through several major classes in the library
and decided on naming and style conventions.  Hopefully our dabbling in it
before led us to a good solution.  IAC, _having_ a convention is the most
important part.

We are also very carefull to have uniform use of parameters.  That is,
functions tend to take the same things in the same order.  And functions in
different classes tend to have the same name.  That makes it easy to keep track
of things.  Instead of many hundreds of functions in C, you have a few
"methods" to remember.  Also variations on a functions will be overloaded
forms.  Like drawing a rectangle with 4 ints, two points, or a rect.  3
functions, one name to remember.

I don't like the hungarian notation.  C++ is typesafe enough, with tools like
implicit conversion and overloading, it is counterproductive. I don't have to
know that carefully what type I'm dealing with, since the call makes sence in
any case.

--John



#: 33487 S5/C++ Study Group            orig=PgUp next=     prev=
    11-Aug-91  21:44:40                 No: 11
Sb: #33442-C++ Programming Style
Fm: Brian Richter 76437,736
To: John M. Dlugosz 70007,4657

I agree that having a naming/style convention is very important.  The things
you mention sound like they make sense, too.  I think that the methods in a
class ought to be so consistent and intuitive that you never have to look at a
reference manual or the include file to remember how to do what you want.

Way back in '85 I first started learning about Windows, and I also got a lot of
hints on style from that, including Hungarian notation.  Recently I found it to
be a lifesaver in a 25,000 line C program.

But C++ is perhaps a different story.  Sometimes I'm guilty of some of the
common mistakes of C programmers moving to C++ (i.e., using pointers for what
really should be references, forgetting 'const', etc.) and since Hungarian
notation helped me in C I naturally carried it into C++.  I still don't quite
"think in C++" completely.  C++ is definitely more typesafe in some ways than
C, and as you say, because of implicit conversion and overloading a decent set
of methods will work with whatever reasonable type of data you give it.  I need
a couple of days to think about it, and then I'll throw together a list of
"what Hungarian notation does for me" which might make an interesting topic of
discussion...

                                       Brian



#: 33520 S5/C++ Study Group            orig= 9   next=     prev= 10
    12-Aug-91  22:04:42                 No: 12 Replies 3
Sb: #33425-C++ Programming Style
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736

>lately I seem to have converted over to Hungarian notation

There was gem'ish thread I had with Charles Petzold about a year ago in another
forum with Charles favoring H.h. and me not.  I wished that I had saved it. In
any event, my perspective is that Hungarian breaks down real quickly. This is
not to say tangents off of the essence of it aren't usable, but and and of
itself, and in general, I just cannot make it practical for my own code.



#: 33526 S5/C++ Study Group            orig=PgUp next= 16  prev=
    13-Aug-91  00:20:25                 No: 13 Replies 2
Sb: #33520-#C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Greg Comeau (ComeauComp) 72331,3421

I beleive that the hungarian notation and other things like it go against the
abilities of C++.  I think that useing overloading and uniform naming goes much
farther.

--John



#: 33536 S5/C++ Study Group            orig=PgUp next=PgDn prev=
    13-Aug-91  04:58:39                 No: 14
Sb: #33526-C++ Programming Style
Fm: Don E. Groves, Jr. 71310,3702
To: John M. Dlugosz 70007,4657

John,
< I beleive that the hungarian notation and other things like it go
< against the abilities of C++.  I think that useing overloading and
< uniform naming goes much farther.

   I agree 100% with you.

  I've always seen "hungarian notation" as a way to bring C++ Type-Safe Linkage
to PRE-C++ compilers'.
  C++ for the most part does away with any need for h.n.
  IMHO  "hungarian notation" works against C++ Overloading.
Jr..



#: 33545 S5/C++ Study Group            orig= 13  next=     prev=PgUp
    13-Aug-91  11:48:48                 No: 15
Sb: #33526-C++ Programming Style
Fm: Brian Richter 76437,736
To: John M. Dlugosz 70007,4657

I did convert to HN before C++, so that could very well be true.  Without HN,
it seems that some sort of conventions in naming would help.  I developed some
on my own but I'm not sure that they're necessarily good or that other people
would like or understand them.  Among the things I came up with that might need
to be distinguished are:

       constants as opposed to variables or #defines
       values for enumerated types
       class names and type names
       class members

I've been writing class names LikeThis and using some form of Hungarian naming
for the others.  Constants start with a "k".  For lack of thinking of something
better, enumerated values have a prefix, an underscore, and then the name of
the value.  Something without the underscore would refer to a variable of that
enumerated type.  Class members got a "z" because I couldn't think of any other
letter I wasn't already using.

Also, there are the obvious things such as distinguishing between ints and
longs, signed and unsigned, pointers and arrays.  These are cases where HN has
probably saved me from getting confused.  Although I'd expect the usual
counterargument (I'm sure someone reading this is at least *thinking* it) that
if your program is designed "properly" you won't get confused anyway...

                                       Brian



#: 33544 S5/C++ Study Group            orig= 12  next=PgDn prev= 13
    13-Aug-91  11:48:41                 No: 16
Sb: #33520-C++ Programming Style
Fm: Brian Richter 76437,736
To: Greg Comeau (ComeauComp) 72331,3421

Sounds like it would have been an interesting thread.  In what sense would you
say Hungarian notation breaks down?  Just that it loses its usefulness, or does
it actually cause some problems or confusion?

                                       Brian



#: 33692 S5/C++ Study Group            orig= 12  next=     prev=PgUp
    16-Aug-91  10:56:39                 No: 17
Sb: #33520-C++ Programming Style
Fm: David Michmerhuizen 70322,617
To: Greg Comeau (ComeauComp) 72331,3421 (X)

absolutly. I think hungarian makes it harder to read code and concentrate on
it's meaning, because it makes it harder to *actually read the code*, ie, say
the words in your mind.  As you read along you have to filter out all those
little prefixes. yuk.



#: 33519 S5/C++ Study Group            orig= 8   next=     prev= 9
    12-Aug-91  22:04:36                 No: 18 One Reply
Sb: #33409-C++ Programming Style
Fm: Greg Comeau (ComeauComp) 72331,3421
To: John M. Dlugosz 70007,4657

>Have both test and set members with the same name.

Why?

Also, if/when possible, this could be a candidate for default arguments.



#: 33527 S5/C++ Study Group            orig=PgUp next=     prev=
    13-Aug-91  00:20:33                 No: 19 One Reply
Sb: #33519-#C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Greg Comeau (ComeauComp) 72331,3421

<<why>> well, it just felt right.  After a hodge podge of classes, we decided
to see what we liked and rewrite to a more standard style. Common names was one
main issue.  One name to remember.  I guess a schema of set_xxx and test_xxx
would be just as easy, but it splits them up in the documentation.  I organized
around a common header for a group of overloaded functions followed by the
declarations of the various forms. It makes for a nice manual, thus far.

I'm not sure of your point.  That this would prevent the set member from having
a default argument?  I've not seen many defaults there actually. If you knew
what you were setting it to, why bother <g>?

On the same thread, I've used functons that set and return the old value. I'm
not sure if _I_ like it, but some users seem to.  As long as it is inline, it
does not waste anything.  It also seems that there are times when that is handy
and other times when 2 lines would be clearer.

Also, some set members set values and flags, or sets of related values. For
example, setting a fill pattern (2 parameters, the second of which can default)
also sets the flag to enable fill patterns.  So set methods can be handier than
just assignments to public members.

--John


#: 33546 S5/C++ Study Group            orig=PgUp next=     prev=
    13-Aug-91  11:48:52                 No: 20 One Reply
Sb: #33527-C++ Programming Style
Fm: Brian Richter 76437,736
To: John M. Dlugosz 70007,4657

My intuition also tells me that it's easier to have "set" and "get" functions
with the same name.  There's no ambiguity because it's easy to see if there are
any arguments, and there are less names to remember...

                                       Brian



#: 33563 S5/C++ Study Group            orig=PgUp next=     prev=
    13-Aug-91  18:01:13                 No: 21 One Reply
Sb: #33546-C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Brian Richter 76437,736

<<less names to remember>>  That not only works across the stuff you know, but
should let you extrapolate.  On seeing a functoin name in a strange class, you
should say "of cource!".  And have no trouble ever remembering it.

I've got lots of classes with a width() member.  Width of a rectangle, a
viewport, the image of a string, a bitmap, etc.  That is just the old promice
of Object Oriented Programming-- the thing understands its message. It _ought_
to have the same name.

--John



#: 33584 S5/C++ Study Group            orig=PgUp next=     prev=
    14-Aug-91  11:50:52                 No: 22 One Reply
Sb: #33563-C++ Programming Style
Fm: Brian Richter 76437,736
To: John M. Dlugosz 70007,4657

Yes, I think you should be able to extrapolate!  Ideally, it would be nice to
be able to just pull in a class and immediately be able to use it, just by
doing whatever seems logical, without looking at the include file or cracking
open a reference manual.  I guess we're not quite at that level of
standardization yet, but that definitely is the promise of OOP.

That's one thing that sometimes concerns me about using other people's
libraries.  Suppose I use the library and somehow it doesn't quite do what I
want.  The cost of buying another library to use is small compared to the
effort of changing my program to conform with the other library's conventions.
If there were some standard ways that things were usually done, I could easily
switch libraries in situations like this.  Knowing I could switch, I would be
less reluctant to use these libraries.

                                       Brian



#: 33591 S5/C++ Study Group            orig=PgUp next=     prev=
    14-Aug-91  15:51:00                 No: 23 One Reply
Sb: #33584-C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Brian Richter 76437,736

Yes, style across multiple libraries is another story.  But internal
consistancy is the first step.

<<Suppose I use the library and somehow it doesn't quite do what I want.>> I
beleive in source code!

--John



#: 33648 S5/C++ Study Group            orig=PgUp next=     prev=
    15-Aug-91  11:58:56                 No: 24 One Reply
Sb: #33591-C++ Programming Style
Fm: Brian Richter 76437,736
To: John M. Dlugosz 70007,4657

I already have the next three stages of the conversation, I think.

1. Yes, source code is good to have, so that you can modify a library if it
doesn't quite do what you want.

2. But then you have to try to learn and understand all the code if you ever
want to change it.

3. Yes, but is it easier to learn someone else's code or to rewrite it all
yourself from scratch?

I've actually seen and had to modify people's code that *would* have been
easier to rewrite from scratch.  I suppose another concern I have is that the
thing that the library doesn't do is not just a matter of added functionality,
but that some basic assumption was made which doesn't hold true for my system.
As a simplified example, suppose I have a windowing library.  I use it, and
then run across a case where I need to write to a window other than the one in
front.  Suppose, however, that when the library puts up a window it just saves
what's behind it to be later restored, implicitly assuming nobody ever writes
to any window other than the one in front.  Writing to a window behind another
one would be a major modification to such a library.

This is an overly easy example, but that's the type of thing I'm concerned
about...

                                       Brian



#: 33662 S5/C++ Study Group            orig=PgUp next=     prev=
    15-Aug-91  19:50:35                 No: 25
Sb: #33648-C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Brian Richter 76437,736

<<3. Yes, but is it easier to learn someone else's code or to rewrite it all
yourself from scratch? >> depends on the code!

How about minor changes, like how the error messages are handled?  Or makeing
memory management match the rest of your program?  Or recompiling for overlays?
Or something really simple that you _know_ could be changed in a second if they
wanted to.  Well you can!  Some things are easy to change, like adding or
removing parameter checking, making simple changes to the meaning of a
function, or writing a new function _almost_ like an old one.

Major functional changes are a different story.  But _having_ it means the
ability to make minor changes.  And supplying source means I can supply lots of
configuration options, too.



#: 33447 S5/C++ Study Group            orig= 1   next=     prev= 8
    10-Aug-91  20:23:14                 No: 26 One Reply
Sb: #33394-C++ Programming Style
Fm: Mark W. Schumann 73750,3527
To: Brian Richter 76437,736


Hey, Brian, that's a Clipper Thing (tm).  Try this in Clipper '87 or 5.0x:

setcolor (mstring1)
? setcolor()       && Prints mstring1
? setcolor (mstring2)   && Prints mstring1
? setcolor (mstring3)   && Prints mstring2

Basically, Nantucket has done exactly what you suggested.  Also, the ProClip
library for Clipper by Genesis uses a similar structure for a couple dozen of
its functions.



#: 33488 S5/C++ Study Group            orig=PgUp next=     prev=
    11-Aug-91  21:44:43                 No: 27
Sb: #33447-C++ Programming Style
Fm: Brian Richter 76437,736
To: Mark W. Schumann 73750,3527

Wow, that *is* exactly what I suggested.  This is good; it makes me much more
confident that perhaps this is a common idiom that will not get people
confused...

                                       Brian



#: 33623 S5/C++ Study Group            orig=ROOT next= 128 prev= 1
    15-Aug-91  01:06:46                 No: 28 Replies 4
Sb: #Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736 (X)

But for arguements sake, just what does being able to distinguish between ints
and long in variable names give you in the first place?  And don't you think
that issue like changing the type of a variable could have negative effects to
this?



#: 33642 S5/C++ Study Group            orig=PgUp next= 93  prev=
    15-Aug-91  11:08:49                 No: 29 Replies 2
Sb: #33623-#Hungarian
Fm: Pete Becker (Borland) 76117,3675
To: Greg Comeau (ComeauComp) 72331,3421

Greg,
       I think that there _used_ to be a great benefit to using Hungarian
notation, back in the bad old days before ANSI C, when Windows was in its
infancy.  You often had to use two or three casts on a variable in order to get
it into the right form for a generic function in the Windows API, and it was
easy to get confused about the type of the variable:

       char *pzStr;

       func( (LONG)(LPSTR)pzStr );

       Most of that ugly casting has gone away, thanks to better type checking
and smarter compilers.  Unfortunately, that ugly notation is still in all the
Windows manuals...
       -- Pete



#: 33646 S5/C++ Study Group            orig=PgUp next= 92  prev=
    15-Aug-91  11:58:46                 No: 30 Replies 2
Sb: #33642-#Hungarian
Fm: Brian Richter 76437,736
To: Pete Becker (Borland) 76117,3675

Actually, Windows is where I got that notation from in the first place. That
was way back in '85 or so, and maybe it has indeed outlived its usefulness.

I'm amazed not to get even one response in favor of this sort of notation. From
what I understand, the arguments against it amount to this:

 1) It is unnecessary with strong typechecking in ANSI C and C++;
 2) It is ugly and inelegant.

To me, the most powerful disadvantage is the implicit one in this discussion:

 3) Lots of really smart people don't like it.

If I'm writing code for someone else to use, I'd want to avoid a notation that
the best software guys dislike.  So to some extent it is better to "follow the
crowd" for this reason.  However, I'm still reluctant to abandon it completely
(perhaps retaining it in some abbreviated form) for several reasons:


[More]

#: 33647 S5/C++ Study Group            orig=PgUp next= 84  prev=
    15-Aug-91  11:58:51                 No: 31 Replies 3
Sb: #33646-#Hungarian
Fm: Brian Richter 76437,736
To: Brian Richter 76437,736

[Continued]


1) It does make it clear what type everything is, without having to go up and
look at the definitions of things.  I've often had to follow someone else's
code, and found it very confusing.  If I see

  thingy->v_qrs

then I have to see what 'thingy' is, and then look at the structure to find out
what 'v_qrs' is.  If he had used HN, just from knowing the type of one such
variable, I'd know that others with the same prefix were the same type.

And I have an immediate rebuttal for that one.  The confusion arises because
poor names were chosen.  If the names were logical, there'd be no confusion.

2) It can make things shorter.  Sometimes part of the information you want to
convey in a name *is* the type of the object.  You might have a temporary
pointer to a record called 'temp_rec_ptr' which could be shortened to 'prTemp'
in HN.  Names become more concise in those cases where it is really important
to convey the type.  Granted, you have to know the abbreviations, but once you
do it shouldn't be any problem.

I don't have a rebuttal for this one yet.  It seems that certain naming
conventions are already part of common usage.  For example, if I saw 'n' or 'i'
as a loop index, I'd guess it's an integer.  But HN would extend this to all
variables.  I suspect someone will be able to argue this point, however...

                                       Brian



#: 33654 S5/C++ Study Group            orig=PgUp next= 76  prev=
    15-Aug-91  16:14:48                 No: 32 Replies 2
Sb: #33647-Hungarian
Fm: Rudyard Merriam 76234,2561
To: Brian Richter 76437,736

Brian

I'll continue the argument by suggesting that typing is unnecesary if you want
to use Hungarian notation. If the type is implicit in the variable name then
why do I have to say 'char * cpName'? The compiler should figure out from the
'cp' that it is a character pointer.

Rud (waiting for the old timers to respond)



#: 33657 S5/C++ Study Group            orig=PgUp next= 42  prev=
    15-Aug-91  16:59:15                 No: 33 Replies 2
Sb: #33654-Hungarian
Fm: Brian Richter 76437,736
To: Rudyard Merriam 76234,2561

I remember when I'd inadvertently come up with a name that started with "N" for
a floating point value and wonder why it wasn't working.  Sometimes I'd get so
frustrated I'd drop all my cards <g>.

For argument's sake, suppose the compiler were smart enough to figure out the
types of variables in Hungarian notation. I'm not sure I see where that would
be a problem...

                                       Brian



#: 33697 S5/C++ Study Group            orig=PgUp next= 39  prev=
    16-Aug-91  11:31:58                 No: 34 Replies 3
Sb: #33657-Hungarian
Fm: Pete Becker (Borland) 76117,3675
To: Brian Richter 76437,736

Brian,
       Now, now, that's really not fair.  I'm sure there are some youngsters
around here who have no idea why using a name that starts with 'N' would mess
up floating point values.
       -- Pete



#: 33720 S5/C++ Study Group            orig=PgUp next=PgDn prev=
    16-Aug-91  18:01:08                 No: 35
Sb: #33697-Hungarian
Fm: Brian Richter 76437,736
To: Pete Becker (Borland) 76117,3675

Well, OK; I didn't want to deprive any "old timers" of their chance to explain
it, but since none have, I get to do it.

This was back when I was learning FORTRAN.  In the FORTRAN of those days, any
variable starting with the letters 'I' through 'N' was automatically an
integer, and you could remember that because those are the first two letters of
'integer'.  As I remember it, the compiler quietly converted the floating point
value to an integer and left the programmer to puzzle over why it didn't work
right.

                                       Brian



#: 33747 S5/C++ Study Group            orig= 34  next= 38  prev=PgUp
    16-Aug-91  23:40:31                 No: 36 One Reply
Sb: #33697-#Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Pete Becker (Borland) 76117,3675 (X)

Hey wait a second!  Don't start calling me old! ;-)  I'm young.  Really I am.
;-)



#: 33761 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  11:23:56                 No: 37
Sb: #33747-Hungarian
Fm: Pete Becker (Borland) 76117,3675
To: Greg Comeau (ComeauComp) 72331,3421

Greg,
       Touchy, touchy...
       -- Pete



#: 33751 S5/C++ Study Group            orig= 34  next=     prev= 36
    17-Aug-91  00:53:11                 No: 38
Sb: #33697-Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: Pete Becker (Borland) 76117,3675 (X)

<<
        Now, now, that's really not fair.  I'm sure there are some youngsters
around here who have no idea why using a name that starts with 'N' would mess
up floating point values. >>

I'm one (thanks for calling me a youngster).

                                                               --Mark



#: 33714 S5/C++ Study Group            orig= 33  next=     prev= 34
    16-Aug-91  17:33:21                 No: 39 One Reply
Sb: #33657-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736

>For argument's sake, suppose the compiler were smart enough to figure out the
>types of variables in Hungarian notation. I'm not sure I see where that would
>be a problem...

But not only would that be superfluous in a language like C/C++, but it
wouldn't be innocuous either.



#: 33779 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  15:02:36                 No: 40 One Reply
Sb: #33714-Hungarian
Fm: Rudyard Merriam 76234,2561
To: Greg Comeau (ComeauComp) 72331,3421

>> >> typees from Hungarian notation

>> supefluous in C/C++...not innocuous either

Why not innocuous?

Rud



#: 33840 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  14:44:14                 No: 41
Sb: #33779-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Rudyard Merriam 76234,2561

>> >> typees from Hungarian notation

>> supefluous in C/C++...not innocuous either

>Why not innocuous?

Because of some of the reasons I've already mentioned in this thread.
Also, my thoughts on this particular comment I made is that if Hungarian
were used as the type, then how would we change the types/names of variables?
That not innocuous IMO.  It could only be maintained it the types were
disjoint from the name.  But that only brings us back to what we already
have.



#: 33682 S5/C++ Study Group            orig= 32  next=     prev= 33
    16-Aug-91  01:28:27                 No: 42 One Reply
Sb: #33654-Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: Rudyard Merriam 76234,2561

Hi, Rud. Wasn't the point of Hungarian that the type of the identifier would be
readily apparent when the name was encountered in the source? I'm playing
devil's advocate here. I hate it myself.


                                                               --Mark



#: 33729 S5/C++ Study Group            orig=PgUp next=     prev=
    16-Aug-91  18:18:23                 No: 43 Replies 4
Sb: #33682-Hungarian
Fm: Rudyard Merriam 76234,2561
To: Mark Betz [GAMERS] 76605,2346

Mark

Petzold says Hunky notation is to avoid type mismatch errors. The MS OS/2
manuals say it is "to help you readily identify the purpose and type of the
funciton parameters and structure fields. ...to make the sources more readable
and informative."

The printed comments appear to agree with your assertion. I suggest that if I
properly name something I can be 80% certain of the variable type and usage
without the Hunky fiddle faddle.

So the original question stands, why not continue the idea an have it a
requirment and let the compiler use it for typing?

Rud



#: 33732 S5/C++ Study Group            orig=PgUp next= 54  prev=
    16-Aug-91  19:15:33                 No: 44 One Reply
Sb: #33729-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Rudyard Merriam 76234,2561

<<"to help you readily identify the purpose and type of the funciton parameters
and structure fields.>>  sounds fishy to me. The paramter should state the type
right next to the value in the declaration.

The closest I've seen to something like that working is in a quick reference
where a bunch of functions are shown as sample calls: foo(v) for example.
Before the list they say that v is a <whatever> and use it in a few sample
calls.

--John



#: 33757 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  02:39:50                 No: 45 Replies 2
Sb: #33732-Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: John M. Dlugosz 70007,4657

What it boils down to, John, is do you want to be able to tell the type without
referring back to the declaration? If the program is large and you can't
remember all the identifiers, then you'll have to refer back to the header, or
wherever it was declared. The argument could be made that you should be working
on well defined parts of the program, and that within the current work domain
you ought to have a pretty good grasp of the identifiers in use. In that sense
I agree with Pete's "hacking the code" comment.

I was thinking about writing a simple program to go through every file in a
project and make a list of all the identifiers above local scope, their types,
and where they are declared. I'm sure there are tools to do this, but it would
be a fun excercise. I started thinking about it yesterday, and it's not as
trivial as I first thought, but shouldn't take too long.

                                                       --Mark



#: 33786 S5/C++ Study Group            orig=PgUp next= 50  prev=
    17-Aug-91  15:18:36                 No: 46 One Reply
Sb: #33757-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Mark Betz [GAMERS] 76605,2346

Well, in C++ variables are defined where needed, and hopefully functions are
small anyway.  No where to go looking.  Classes do define all the contents, and
referring to the class definition in the header is perfectly natural. I usually
keep it in an inset window in the upper right corner of the screen.

A utility to spot all global variables might be handy, for studying code you
just got.  You mean globaly public values (which will be in a header somewhere,
too) or static variables in a file?

--John



#: 33793 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  16:52:48                 No: 47 One Reply
Sb: #33786-Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: John M. Dlugosz 70007,4657

Hi, John. I expect to write the utility to list all identifiers, static and
otherwise, that have greater than local scope. That should include class and
struct members as well. It's also got to keep track of the types of al the
identifiers, some of which may inherit their types, so it's going to be an
interesting project.

                                               --Mark



#: 33805 S5/C++ Study Group            orig=PgUp next=     prev=
    18-Aug-91  03:08:53                 No: 48 One Reply
Sb: #33793-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Mark Betz [GAMERS] 76605,2346

Well, it was the wish for a cross-referencer that got me on the road to
studying C++ in a more serious way.  Good luck.

--John



#: 33821 S5/C++ Study Group            orig=PgUp next=     prev=
    18-Aug-91  18:21:23                 No: 49
Sb: #33805-Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: John M. Dlugosz 70007,4657

Thanks! I may need to come to you for help on it <g>. It'll be freeware, so
I'll likely post my ideas and ask everyone to contribute.


                                                       --Mark



#: 33842 S5/C++ Study Group            orig= 45  next=     prev= 46
    19-Aug-91  14:44:26                 No: 50 One Reply
Sb: #33757-#Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Mark Betz [GAMERS] 76605,2346 (X)

>What it boils down to, John, is do you want to be able to tell the type
>without referring back to the declaration? If the program is large and you
>can't remember all the identifiers, then you'll have to refer back to the

Well, there are (proper?) ways around that.  But IMO, just trying to grasp a
humongous project that is beyond the scope of one individual make it
apparent that this is not a language problem at heart.  Tools are the route
to go.  Static analysis is one route.  Browsers are another.  But not quite
either one or the other is the route to go.  Both are and hence this C++
environment idea you hear me mention once is a while is the ultimate goal.
Not much different that the way some spelling checkers and help systems work
not for starters would be nice.




#: 33855 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  16:14:55                 No: 51 One Reply
Sb: #33842-Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: Greg Comeau (ComeauComp) 72331,3421

Good point, Greg. I think it isn't a language issue. I'm considering writing a
small program to cross ref all identifiers in a project by looking at either
the project or make files, and then parsing each source file to find the
identifiers and their types. Would something like this be useful, do you think?

                                                       --Mark



#: 33919 S5/C++ Study Group            orig=PgUp next=     prev=
    20-Aug-91  15:19:25                 No: 52 One Reply
Sb: #33855-#Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Mark Betz [GAMERS] 76605,2346 (X)

It would have use.  Just don't underestimate its complexity.  You got many
issue to resolve if done properly.



#: 33924 S5/C++ Study Group            orig=PgUp next=     prev=
    20-Aug-91  15:37:08                 No: 53
Sb: #33919-Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: Greg Comeau (ComeauComp) 72331,3421

Thanks Greg. That's something I've come to realize as I contemplated the
project. Since you've brought up the idea of "done properly" let me throw the
question into the arena: What should a C++ identifier cross-referencer do if
it's to be "done properly"?


                                                       --Mark



#: 33748 S5/C++ Study Group            orig= 43  next=PgDn prev= 44
    16-Aug-91  23:40:33                 No: 54
Sb: #33729-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Rudyard Merriam 76234,2561 (X)

Why not let the compiler use it for typing?  Well, enough people seem to
dislike it, even just from a readability standpoint.



#: 33756 S5/C++ Study Group            orig= 43  next= 72  prev=PgUp
    17-Aug-91  01:54:57                 No: 55 Replies 2
Sb: #33729-#Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: Rudyard Merriam 76234,2561 (X)

Ok, I see where you're heading. I thought you were saying that the compilers
already did something with Hungarian notation.

It's an interesting idea. Instead of char *somechar you would declare
cpSomeChar and the compiler would know what it is by the first two letters. It
would be workable, and you'd gain explicit type recognition based on identifier
names. Not a bad idea at all. How would you handle custom types? Have to allow
the programmer to define new type codes as we currently can.


                                                       --Mark




#: 33762 S5/C++ Study Group            orig=PgUp next= 67  prev=
    17-Aug-91  11:24:06                 No: 56 Replies 3
Sb: #33756-#Hungarian
Fm: Pete Becker (Borland) 76117,3675
To: Mark Betz [GAMERS] 76605,2346

Mark,
       NO, NO, NO!!!!  You kids who haven't had the benefit of programming in
FORTRAN obviously haven't learned the dangers of implicit types.  But putting
that aside, and assuming arguendo that implicit types are a good thing, you
still have a significant decision to make: are explicit type declarations
required (even though they're redundant)?  If not, you've got a BASIC-style
maintenance problem if you ever change the name of a variable and miss one or
two occurrences of its name. If so, how do you handle a conflict between the
declared type and the implicit type?  I suppose it has to be an error.  Which
gets you right into the nit-picking style of Pascal. No thanks...
       -- Pete



#: 33766 S5/C++ Study Group            orig=PgUp next=PgDn prev=
    17-Aug-91  13:53:14                 No: 57
Sb: #33762-Hungarian
Fm: Brian Richter 76437,736
To: Pete Becker (Borland) 76117,3675

>> ...nit-picking style of Pascal

That's the best argument I've heard yet.  HN is certainly one step closer to
implicit types.  If you use them correctly, you evidently expect all the
prefixes to match.  And whether you check or the compiler checks, it sort of
amounts to the same thing...

                                       Brian



#: 33791 S5/C++ Study Group            orig= 56  next= 66  prev=PgUp
    17-Aug-91  16:16:32                 No: 58 One Reply
Sb: #33762-Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: Pete Becker (Borland) 76117,3675

Good point, Pete. And thanks again! That's twice you've inplied I'm a young'un
<g>. I may be... but sometimes 31 feels old.

I see what you're saying. In C++ to alter the type of an identifier you simply
change the declaration. In any case, while I might approve of the idea of
self-identifying types in theory, I agree with you that it's a solution in
search of a problem. When I'm maintaining code I have to understand it to an
extent that makes me familiar with what the identifiers are and what they do
anyway. To do less is to risk breaking the thing.


                                                       --Mark



#: 33844 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  14:44:32                 No: 59 One Reply
Sb: #33791-#Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Mark Betz [GAMERS] 76605,2346 (X)

Jeesh are here you got me think you were 15 in your previous message. Me: I
must be a youngen too: I'm 32.  Or is that where the line is drawn? ;-)



#: 33856 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  16:14:59                 No: 60 One Reply
Sb: #33844-Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: Greg Comeau (ComeauComp) 72331,3421

>> think you were 15...

Well, there are probably many 15 year-olds who know more about C++ than I do
<g>.

You're right, the cut-off is 31. Sorry... old man :)


                                                       --Mark



#: 33866 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  17:45:08                 No: 61 Replies 2
Sb: #33856-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Mark Betz [GAMERS] 76605,2346

I'm 24, and starting to feel "old".  Why?  I'm putting socks on my birthday
list.

--John



#: 33884 S5/C++ Study Group            orig=PgUp next= 65  prev=
    19-Aug-91  20:51:44                 No: 62 Replies 2
Sb: #33866-Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: John M. Dlugosz 70007,4657

That *is* old. Not being able to think of anything neater than that means that
a) you are losing your imagination, or b) you are too lazy/busy to go to the
store and buy socks. I fall firmly in category 2 (I hope) <g>.


                                                       --Mark



#: 33897 S5/C++ Study Group            orig=PgUp next=PgDn prev=
    20-Aug-91  00:25:58                 No: 63
Sb: #33884-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Mark Betz [GAMERS] 76605,2346 (X)

No, its just that this is now something I really need.  I spend fifty bucks for
a box of socks.  (special order from Burlington)

--John



#: 33911 S5/C++ Study Group            orig= 62  next=     prev=PgUp
    20-Aug-91  11:50:56                 No: 64
Sb: #33884-Hungarian
Fm: Rudyard Merriam 76234,2561
To: Mark Betz [GAMERS] 76605,2346 (X)

Mark

You have to realize that John's socks are big! They could be used to cover all
the golf clubs in a set at one time! <g>

Rud



#: 33909 S5/C++ Study Group            orig= 61  next=     prev= 62
    20-Aug-91  10:29:27                 No: 65
Sb: #33866-Hungarian
Fm: Skip Key 73130,2102
To: John M. Dlugosz 70007,4657

John,
       You _are_ old at 24.  I'm 22 and I feel old most of the time so you must
be<g>.

Skip



#: 33843 S5/C++ Study Group            orig= 56  next=     prev= 58
    19-Aug-91  14:44:28                 No: 66
Sb: #33762-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Pete Becker (Borland) 76117,3675

Exactamundo!



#: 33787 S5/C++ Study Group            orig= 55  next=     prev= 56
    17-Aug-91  15:18:41                 No: 67 One Reply
Sb: #33756-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Mark Betz [GAMERS] 76605,2346

Here is a tangent.  I'm designing a little languge for an editor macro
language, and my big idea at this point is typeless (more typeless than
anything you've seen before!).  Would a tagged notation make sence in this
case?

--John



#: 33794 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  16:52:51                 No: 68 One Reply
Sb: #33787-Hungarian
Fm: Mark Betz [GAMERS] 76605,2346
To: John M. Dlugosz 70007,4657

That'd be hard to answer, John, without knowing what the macro language will
do. Most macro languages I've used in application programs don't deal with the
concept of type much at all, ouside of numerical types. What's the basic goal
of the language?

                                                       --Mark



#: 33806 S5/C++ Study Group            orig=PgUp next=     prev=
    18-Aug-91  03:09:01                 No: 69 One Reply
Sb: #33794-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Mark Betz [GAMERS] 76605,2346

<<the basic goal of the language>>  It should be powerful enough to implement
most of the editor commands in it.  functions can be bound to C++ code, which
will handle all the primitives.

I will be object oriented, in the sense that you can take an existing object
(say, a edit window for C code, which has key bindings and functions used by
them and whatnot) and make a new thing from it, adding code, changing code,
altering settings, etc., but not messing up the original. Then you can throw it
away when done with it and it goes away seemlessly.

Everything it deals with is an object, with its own member functions.
Primitives are numbers, strings, arrays, functions, messages. Then you have
structured types, which hold a bunch of named fields. (fields can hold
functions, and you can then send messages to call them)

The idea is that you have class scope.  when "in" a member function, your
symbol table are other fields of that object.  To make something a little
different, you clone an existing object and start making changes.  The
implementation acually shares as much as possible between the two.

For the class things, you see that there are no types.  Every object can have
fields added and removed at will.  An object is not of a type; rather it just
has a bunch of named fields.  It may happen to have the same names as another
object.

What do you think?

--John

P.S.  change the subject when you reply!



#: 33845 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  14:44:36                 No: 70 One Reply
Sb: #33806-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: John M. Dlugosz 70007,4657

I think that you're going to have some fun, and possible some interesting
research in front of you.

Do you surmise that you'll be able to resolve all the contexts of a given class
to resolve ambiguity?



#: 33867 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  17:45:13                 No: 71
Sb: #33845-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Greg Comeau (ComeauComp) 72331,3421

sorry, I lost the thread.



#: 33758 S5/C++ Study Group            orig= 43  next=     prev= 55
    17-Aug-91  05:40:11                 No: 72 One Reply
Sb: #33729-Hungarian
Fm: Sidney Markowitz 75140,137
To: Rudyard Merriam 76234,2561 (X)

 >> why not ... let the compiler use it for typing? <<

In ANSI C and in C++ there is already a way to indicate the type of a variable
in a way that avoids type mismatch errors and is enforced by the compiler. This
way is more flexible than Hungarian notation in that it can handle any type,
including user defined structs and classes, it does not interfere with the
readability of descriptive variable names, and it localizes the changes that
are necessary when you decide to change the data structures used in
implementing your program.

Instead of specifying the type in the first few characters of a variable's
name, you specify it explicitly in the variable definition or declaration, or
in the function prototype.

 -- sidney



#: 33780 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  15:02:41                 No: 73 Replies 2
Sb: #33758-#Hungarian
Fm: Rudyard Merriam 76234,2561
To: Sidney Markowitz 75140,137 (X)

sidney

But FORTRAN did use a primitive form of HN to type variables. Why did languages
like C/C++ and Pascal reject that usage and introduce type declarations?

I think the best argument is the localization of changes.

Rud




#: 33801 S5/C++ Study Group            orig=PgUp next=PgDn prev=
    17-Aug-91  23:04:45                 No: 74
Sb: #33780-Hungarian
Fm: Sidney Markowitz 75140,137
To: Rudyard Merriam 76234,2561

Rud -

FORTRAN introduced a primitive form of HN to type variables, and it provided a
chance for people to learn what is wrong with that system. 1) FORTRAN proved to
be too poor in the number of types available. Extensions to the type system did
not continue the implicit typing of variables based on name. 2) If you are
going to rely on the variable name to implicitly type it, then you have to not
require explicit declarations of variables. That leads to typos not being
caught by the compiler if variables don't have to be declared before use. If
you have to declare variables before use, then you aren't fully relying on the
implicit typing based on the name.

I agree that localization of changes is an important reason, but I also am
strongly in favor of a style of programming in which you make up data
structures to match your algorithms and encapsulate them as types with their
own functions. In OOP, that's called classes and methods. And if you do that,
your type names are class names and HN makes absolutely no sense at all.

 -- sidney



#: 33846 S5/C++ Study Group            orig= 73  next=     prev=PgUp
    19-Aug-91  14:44:38                 No: 75
Sb: #33780-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Rudyard Merriam 76234,2561

But FORTRAN's HN was implicit.  Even worse IMO.  Further compounded with
FORTRAN was that you could also be explicit and if I recall proporly could also
override any defaults.  My comment: Oy!



#: 33688 S5/C++ Study Group            orig= 31  next= 83  prev= 32
    16-Aug-91  09:00:19                 No: 76 Replies 2
Sb: #33647-Hungarian
Fm: Ben Sano 72401,2736
To: Brian Richter 76437,736

Brian

Sounds almost as useful as a comment an even less likely to be changed in
case of maintainence, since you have to change it in more then one place.

And since C++ allows you to define new types why the possiblities are
ENDLESS.

aLstkUGI of course is a variable called 'a' that is a Stack of Unbounded
implementation with garbage collection and an iterator.

I would rather write COBOL.

--Ben



#: 33715 S5/C++ Study Group            orig=PgUp next= 80  prev=
    16-Aug-91  17:33:24                 No: 77 One Reply
Sb: #33688-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Ben Sano 72401,2736

>aLstkUGI

Wait!  What's the L mean? ;-)



#: 33735 S5/C++ Study Group            orig=PgUp next=     prev=
    16-Aug-91  20:31:55                 No: 78 One Reply
Sb: #33715-Hungarian
Fm: Ben Sano 72401,2736
To: Greg Comeau (ComeauComp) 72331,3421 (X)

Greg
 >Wait! What's the L mean?

Why, it used to be a List but when I changed it into a Stack I forgot to
change the name! ;-)

--Ben



#: 33745 S5/C++ Study Group            orig=PgUp next=     prev=
    16-Aug-91  23:03:57                 No: 79
Sb: #33735-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Ben Sano 72401,2736 (X)

Oy!



#: 33721 S5/C++ Study Group            orig= 76  next=     prev= 77
    16-Aug-91  18:01:10                 No: 80 One Reply
Sb: #33688-Hungarian
Fm: Brian Richter 76437,736
To: Ben Sano 72401,2736

That's been my experience in C++ too; you just get too darn many abbreviations
to remember.  (I like your example!)  This is what made me doubt HN enough to
start this discussion...

                                       Brian



#: 33736 S5/C++ Study Group            orig=PgUp next=     prev=
    16-Aug-91  20:32:02                 No: 81 One Reply
Sb: #33721-Hungarian
Fm: Ben Sano 72401,2736
To: Brian Richter 76437,736

Brian

 Glad you liked the examples but I didn't make them up you know, the
classification system is adapted from Grady Booch's Ada components.

Which goes like this:

  Software Form ::= Concurrency Form, Space Form, Iterator Form, Garbage
                    Collection Form;

  Concurrency Form ::= Sequential | Guarded | Concurrent | Multiple;
  Space Form       ::= Bounded | Unbounded;
  Iterator Form    ::= Noniterator | Iterator;
  Garbage Collected Form ::= Managed | Unmanaged | Controlled;

In languages that allow Abstract Data Types it not a joke, in C++ which
tries very hard and largely successfully to make user defined types look
like those of the base language Hungarian notation becomes a disaster.

--Ben



#: 33767 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  13:53:18                 No: 82
Sb: #33736-Hungarian
Fm: Brian Richter 76437,736
To: Ben Sano 72401,2736

So are you saying that for such Abstract Data Types, HN really helps?

                                       Brian



#: 33713 S5/C++ Study Group            orig= 31  next=     prev= 76
    16-Aug-91  17:33:16                 No: 83
Sb: #33647-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736

>1) It does make it clear what type everything is, without having to go up and
>look at the definitions of things.  I've often had to follow someone else's
>code, and found it very confusing.

But the price to pay for looking up the stuff (shouldn't ya be sure
anyway??) is lower than the price of a misleading name.  No different than
an ambiguous, bogus, or outdated comment.

Also, I don't see how issues like C's typedef and/or C++ class names can be
maintained in any managable order (ah, some of my examples with Petzold are
starting to come back!).  Again, it just breaks down too quickly.

Anyway, I don't think it a burden for a programmer to know what her/his
program is doing.

>It seems that certain naming conventions are already part of common usage.
>For example, if I saw 'n' or 'i' as a loop index, I'd guess it's an integer.

As I mentioned the idea is not all that far fetched, and most certainly
names like i are idioms for a temp integer or somesuch.  Or p for pointer.
But I don't think it can go much further than that for general programming.
However, I do see it having a more, but limited, use in sub-systems, perhaps
especially where names clashes would normally occur.



#: 33712 S5/C++ Study Group            orig= 30  next=     prev= 31
    16-Aug-91  17:33:07                 No: 84 One Reply
Sb: #33646-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736

>To me, the most powerful disadvantage is the implicit one in this discussion:
>
> 3) Lots of really smart people don't like it.

To me, it's a serious mistake to decide based up that.  Realize that the
so-called smart people suffer from knowing too much for their own good many
times.  Also, the so-called smart people have tendencies to cult'isize.
That's bad all around.  Smarties should be 3rd degree questioned and if they
can't defend themselves should be literally boo'd right off the stage and of
course, not be listened to just because they said something wrong amidst a
bunch of right stuff.



#: 33768 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  13:53:24                 No: 85 Replies 2
Sb: #33712-#Hungarian
Fm: Brian Richter 76437,736
To: Greg Comeau (ComeauComp) 72331,3421

I didn't want to admit it, but of course you're absolutely right!  "Lots of
really smart people don't like it" is not on its own a valid reason not to use
HN.  Realizing this makes the decision no easier than it was in the beginning.

OTOH, I think all youse guys defended yourselves pretty well. <g>

But theoretically, then, even after listening to this entire one-sided
discussion, if I still thought that HN was good I should go right on using it.
Evidently Petzold feels strongly enough about it to do just that.  But I have
two arguments that are related but not the same as my original one, given here
in order of increasing persuasive power:

1) Lots of experienced programmers have evidently found it not to be helpful.
I admit, this one is somewhat of a guess on my part.  I'll bet a good number of
the people who argue against HN have never even tried it; they just don't think
it looks nice.  And I do know from experience that it's not nearly so cryptic
in actual use as it looks to an outsider reading it.  But, in general, I think
I know who's who out there, and many may have dabbled in Windows programming or
had some other sort of actual experience.

Not only that, but...


2) Most of the programming world does not accept HN.  This is perhaps similar
to my original argument, in a sense.  But I figure that when I'm writing code,
it's not just for myself to read.  Other people are going to have to read it
too.  So even if I personally find something easier to read, if nobody else can
understand it I'm putting myself at a disadvantage.

And suppose I were going to write a class library of some sort, which I thought
could really be better than anything else on the market.  If I stuck to HN,
most people would take that as a minus and probably wouldn't buy my library.

So I think using a notation that is acceptable to others is very important. If
I really didn't care about other people reading it, I wouldn't even have to use
comments, because what programmer would be stupid enough not to remember his
own code! <g>

Seriously, it's a tough question, but I think I'm going to stop using HN. I'm
working on some experiments in de-Hungarianizing something right now...

                                       Brian



#: 33788 S5/C++ Study Group            orig=PgUp next= 90  prev=
    17-Aug-91  15:18:46                 No: 86 Replies 2
Sb: #33768-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Brian Richter 76437,736

A different situation:  you are looking at a code _fragment_ in a book. Where
to look for variable definitions and functions?  You want full info on that
page.  Tagging the types of the variables (and omitting the definitions from
the fragment) might make sence.

--John



#: 33796 S5/C++ Study Group            orig=PgUp next=PgDn prev=
    17-Aug-91  17:32:49                 No: 87
Sb: #33788-Hungarian
Fm: Brian Richter 76437,736
To: John M. Dlugosz 70007,4657

If I were writing a book, I might do something like this:

 char s[];
 char* p;
 char c;

 ...

 for (p = s; *p != '\0'; p++)
   *p = c;

To briefly hop threads, I'd code it this way and expect the compiler to know
that it's comparing something with zero.  It's just clearer this way...

                                       Brian



#: 33848 S5/C++ Study Group            orig= 86  next=     prev=PgUp
    19-Aug-91  14:44:47                 No: 88 One Reply
Sb: #33788-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: John M. Dlugosz 70007,4657

As I commented about the HN thread discussion I had with Petzold now in
oblivion, any chance of getting this thread lib'ed up somehow?



#: 33868 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  17:45:18                 No: 89
Sb: #33848-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Greg Comeau (ComeauComp) 72331,3421

Sure.  I'll grab the Hungarian thread tonight and upload.  I've been meaning to
grab the #now what thread anyway.

--John



#: 33847 S5/C++ Study Group            orig= 85  next=     prev= 86
    19-Aug-91  14:44:44                 No: 90 One Reply
Sb: #33768-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736

>I'll bet a good number of the people who argue against HN have never even
>tried it; they just don't think it looks nice.

If it matters any, although I've never used the HN that Windows uses, I have
invented my own both in typed and untypes languages and except for rarer
situations it was most certainly more trouble than it was worth.
Furthermore, it was bad enough to inflict me on myself, but I also inflicted
such composition upon others for a brief period of time.  No go.



#: 33873 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  17:51:15                 No: 91
Sb: #33847-Hungarian
Fm: Brian Richter 76437,736
To: Greg Comeau (ComeauComp) 72331,3421

This thread is going to stop me just short of inflicting it on others. Although
there may be some code of mine out there that's too late to stop before others
see it.

I'm relieved to hear that I'm not the only one who has tried it.  It *sounded*
good...

                                       Brian



#: 33693 S5/C++ Study Group            orig= 29  next=     prev= 30
    16-Aug-91  10:58:27                 No: 92
Sb: #33642-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Pete Becker (Borland) 76117,3675 (X)

>       I think that there _used_ to be a great benefit to using Hungarian
>notation, back in the bad old days before ANSI C, when Windows was in its
>infancy.

There used to be only in *some* contexts.  That's what I meant by my
previous comment in this thread of "This is not to say that tangents off the
essence of [Hungarian] aren't usable, but in and of itself [Hungarian] is
not practical."  That is to say: I do see the merit in naming conventions,
particularly in a sub-system like Windows.  I do not see it being used
generically in total all over though, whether in "Classic C" or not.  And
even having said what I've said about it having a limited use, something
like Windows has most certainly brought it past the limit.



#: 33645 S5/C++ Study Group            orig= 28  next= 122 prev= 29
    15-Aug-91  11:58:41                 No: 93 Replies 4
Sb: #33623-Hungarian
Fm: Brian Richter 76437,736
To: Greg Comeau (ComeauComp) 72331,3421

For argument's sake, then, it makes implicit conversions more apparent.  If you
have

       lSize = nNumBytes

then you know that 'nNumBytes' can only hold an integer value, and if this
occurs all over, you can think to yourself, "Gee, either 'lSize' only needs to
be an 'int' or 'nNumBytes' ought to be a 'long'."

Changing the type of a variable isn't too much of a problem; it's just a
find-and-replace operation.  It's a bit tedious, but doesn't present any
special difficulties.

I must say, I'm surprised that of all the responses on this topic, not one has
been in favor of Hungarian notation!

                                       Brian



#: 33660 S5/C++ Study Group            orig=PgUp next= 98  prev=
    15-Aug-91  18:40:10                 No: 94 One Reply
Sb: #33645-Hungarian
Fm: Steven E. Patamia 72310,3627
To: Brian Richter 76437,736

Brian,
       Well, here is a response from someone who is not an old hand at C, but
who has managed to accomplish some non-trivial work AND who, upon surveying the
Window's world finds so-called Hungarian notation to be mildly irritating.

       I should start by conceding that there are plenty of times that the
media is the message and all I want is a rationale to guide name formation of
something so that I don't have to agonize over it.  However, if the scope of
such a name is larger than some locality that I can survey in a glance, then
even this is less desirable than inventing a more meaningful moniker.

       Without enumerating all the excellent reasons propounded, let me just
generally agree with the proposed reasons why this notation is obsolete and add
a final observation.  If I have to expend intellectual effort in name
formation, I'd much rather invest in creating an evocative name than in
adhering to some convention whose main goal is simply to highlight aspects of a
variable I'm trying hard not to have to concentrate on in the first place.

SEP



#: 33722 S5/C++ Study Group            orig=PgUp next=     prev=
    16-Aug-91  18:01:15                 No: 95 One Reply
Sb: #33660-Hungarian
Fm: Brian Richter 76437,736
To: Steven E. Patamia 72310,3627

I found my excursion into the Windows world so irritating that I couldn't be
sure whether it was HN or the API in general that was worse.  HN was a habit
that I picked up from Windows, and I just assumed Petzold wouldn't lie to me.
I even at one point started adopting some of the spacing he uses in his book.
Then suddenly I looked at my programs and said "Geez, this looks ugly!"  I
actually edited all the modules in my program to return to more "normal"
spacings.

I never thought about your last reason, but I do think it makes sense.  In a
sense, I think you're saying that HN overemphasizes the use of the type in a
name, and that there are other more important things that a name should convey.
It tends to make one almost lazy and not have to think of decent variable
names.

In one important project that I was doing with someone else, we'd actually
spend a half hour or an hour just coming up with the appropriate names for
certain data structures.  When we did so, the effort paid off tremendously,
because it made the entire program more readable.  As I look back, I agree that
these names are far better than anything HN could have provided.

                                       Brian



#: 33812 S5/C++ Study Group            orig=PgUp next=     prev=
    18-Aug-91  13:56:27                 No: 96 One Reply
Sb: #33722-#Hungarian
Fm: Steven E. Patamia 72310,3627
To: Brian Richter 76437,736 (X)

Brian,
       Yes I think we agree completely.  What the HN did was mitigate a
weakness that is possibly obviate by more contemporary thinking.  I'm thinking
of the logical extremes of HN in the context of "Object Orientation".

       Think about C++ Classes (something I'm forced to do a lot lately). In
the tradition of HN, how should you name a class object?  Its a question that
instantly points up the absurdity of the idea!  One names "objects" to convey
the essence of what they "represent".  Not only that, but what sense does it
make to name a class object to match its "type" -- there being as many "types"
as you are willing to invent!  Now think backwards a little. Every data
"object" whether a user-defined class or not is nonetheless an "object" if we
are oriented that way.  In that context, why should we be naming these simpler
objects in such an arcane way when naming more complex or abstract ones is
obviously inappropriate?

       Given type checking and adherence to OOP, HN just melts away as
irrelevant.

SEP




#: 33817 S5/C++ Study Group            orig=PgUp next=     prev=
    18-Aug-91  16:22:09                 No: 97
Sb: #33812-Hungarian
Fm: Brian Richter 76437,736
To: Steven E. Patamia 72310,3627

Agreed.  My misgivings about this began when I carried HN right over from C
into C++.  And the result was very much what you say; it just didn't make much
sense.

As an experiment, I've taken that C++ program and partially de-Hungarianized it
(or performed a Hungarianectomy on it?).  Anyway, results were favorable; the
program's readability considerably improved.  It just looks clearer and more
elegant.  And thanks to C++'s strict typing, I don't think there's any danger.
The compiler will let you know if you mess up the types of things...

                                       Brian



#: 33691 S5/C++ Study Group            orig= 93  next= 103 prev= 94
    16-Aug-91  10:28:31                 No: 98 Replies 2
Sb: #33645-Hungarian
Fm: Karl M. Beem 72311,3467
To: Brian Richter 76437,736

Hungarian is wrong. 1) The compiler knows nothing of it. 2) I prefer to
organize my code so that a single change in a key header file
   produces a large difference in generated code.  If you used HN and
   decided to change types, you have to change every instance of the name.



#: 33716 S5/C++ Study Group            orig=PgUp next=PgDn prev=
    16-Aug-91  17:33:27                 No: 99
Sb: #33691-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Karl M. Beem 72311,3467

>If you used HN and decided to change types, you have to change every
>instance of the name.

But not only that, but perhaps every instance of a related/copied/assigned/etc
name from that name.  Tis not simple.



#: 33724 S5/C++ Study Group            orig= 98  next=     prev=PgUp
    16-Aug-91  18:01:26                 No: 100 One Reply
Sb: #33691-Hungarian
Fm: Brian Richter 76437,736
To: Karl M. Beem 72311,3467

I agree with reason 1 but I'm not sure I understand reason 2.  What does the
fact that a single change in a key header file produces a big difference in
generated code have to do with HN?

Not that I'm arguing for HN, but if modules are messing with structure or class
members directly by their names, they might not be able to silently ignore any
change in this member's type.  If they're members of a class then it's better
to use inlined access functions anyway, so the modules don't even have to know
if they're accessing a member or calling a function or whatever...

                                       Brian



#: 33759 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  08:33:34                 No: 101 One Reply
Sb: #33724-#Hungarian
Fm: Karl M. Beem 72311,3467
To: Brian Richter 76437,736 (X)

If you decide to change iNthings to a long, you would have to change every
occurrence of the name to lNthings.  Ok, suppose that you do so, in a very
large function.  Then the compiler tells you that you have 2 lNthings.
Hopefully, you have a backup.

Karl




#: 33770 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  13:53:33                 No: 102
Sb: #33759-Hungarian
Fm: Brian Richter 76437,736
To: Karl M. Beem 72311,3467

I agree.  Of course, this is true any time you have to change the name of
something.  I guess the point is that HN gives you another reason to do so
where you wouldn't have to otherwise...

                                       Brian



#: 33694 S5/C++ Study Group            orig= 93  next= 108 prev= 98
    16-Aug-91  10:58:33                 No: 103 One Reply
Sb: #33645-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736

>Changing the type of a variable isn't too much of a problem; it's just a
>find-and-replace operation.  It's a bit tedious, but doesn't present any
>special difficulties.

But that's just my poiny: it *is* a problem.  What about cascading?
Also, what about a variable name that you've gotten familiar with being
changed?  Imagine the number of typo's you'd have?  Now, imagine that
variable name being changed by another team member not telling you about it.
And of course, imagine the name being changed, and then being reintroduced
(either replacing the replacer name or in addition to the replacer name) at
some later date?  Are we having fun yet? ;-)



#: 33723 S5/C++ Study Group            orig=PgUp next=     prev=
    16-Aug-91  18:01:21                 No: 104 Replies 2
Sb: #33694-Hungarian
Fm: Brian Richter 76437,736
To: Greg Comeau (ComeauComp) 72331,3421

Don't think for a moment that I'm trying to argue for HN here, but I don't
think that's a valid reason.  I'd be a lot worse off if another team member
changed the type of a variable and *didn't* change the name!  The program would
link correctly because the linker doesn't know what types the variables are,
and it would be a very difficult problem to track down.  (I know, it's happened
to me!)

Typos are the least of your problems; at least the compiler will catch them for
you.  Also, I still say find-and-replaces are tedious, but not a problem.  If
you miss any, the compiler or linker will tell you.

This doesn't have to do with HN in a sense but equally applies to *any* change
of a variable name.  One thing I have found is that if a variable has changed
in function as a program has evolved, it does not pay to be timid about
renaming it.  The increase in understandability generally seems to outweigh the
trouble to edit the files to change the name.

I agree with many of the other arguments against HN, but I think that "because
it's a lot of trouble to change the name" is a very weak reason...

                                       Brian



#: 33733 S5/C++ Study Group            orig=PgUp next= 107 prev=
    16-Aug-91  19:15:37                 No: 105 One Reply
Sb: #33723-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Brian Richter 76437,736

If I change something, I _will_ rename it.  That will make sure I don't have
any old uses sneeking in.



#: 33771 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  13:53:37                 No: 106
Sb: #33733-Hungarian
Fm: Brian Richter 76437,736
To: John M. Dlugosz 70007,4657

I do too.  Sometimes I've even had one variable using a somewhat illogical name
that I really wanted to use for a different variable.  In that case I'd first
rename the variable whose name I wanted to steal to something different.  Then
I'd make sure it compiles and runs OK.  Next, I'd rename the second variable to
the old name of the first variable.

                                       Brian



#: 33742 S5/C++ Study Group            orig= 104 next=     prev= 105
    16-Aug-91  23:03:42                 No: 107
Sb: #33723-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736 (X)

>I agree with many of the other arguments against HN, but I think that "because
>it's a lot of trouble to change the name" is a very weak reason...

I won't argue this to my death, but I will say that even if I agreed, it's
just one argument in a whole bunch, and hence weak or not, it's still a
minus.



#: 33698 S5/C++ Study Group            orig= 93  next=     prev= 103
    16-Aug-91  11:32:04                 No: 108 Replies 2
Sb: #33645-Hungarian
Fm: Pete Becker (Borland) 76117,3675
To: Brian Richter 76437,736

Brian,
       If someone doesn't know the type of a variable named numBytes, why are
they using it?  Hmm, probably because they're hacking the code instead of
thinking about it.
       -- Pete



#: 33707 S5/C++ Study Group            orig=PgUp next= 112 prev=
    16-Aug-91  17:03:39                 No: 109 One Reply
Sb: #33698-Hungarian
Fm: John M. Dlugosz 70007,4657
To: Pete Becker (Borland) 76117,3675

    If someone doesn't know the type of a variable named numBytes, why are
 they using it?
 ^^^^
error on line 2: disagreement in number with anteceedent

Don't you _hate_ strong type checking?  <g>  Perhaps english should not tag
words with attributes such as number and tense.  Or the rules should be made
more uniform.  Better yet, remove pronouns entirely.  That is just a pointer,
and you know how pointers can get you in trouble!

--John



#: 33781 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  15:02:45                 No: 110 One Reply
Sb: #33707-Hungarian
Fm: Rudyard Merriam 76234,2561
To: John M. Dlugosz 70007,4657

John

You need to upgrade your English checker. The use of 'they' in situations where
he/she should technically appear is becoming accepted usage.

Rud



#: 33908 S5/C++ Study Group            orig=PgUp next=     prev=
    20-Aug-91  10:29:24                 No: 111
Sb: #33781-Hungarian
Fm: Skip Key 73130,2102
To: Rudyard Merriam 76234,2561

My mother the English teacher would shoot you<g>.




#: 33725 S5/C++ Study Group            orig= 108 next=     prev= 109
    16-Aug-91  18:01:30                 No: 112 One Reply
Sb: #33698-Hungarian
Fm: Brian Richter 76437,736
To: Pete Becker (Borland) 76117,3675

Excellent point, and I knew somebody was going to say that.  I agree that if
it's so important for somebody to constantly be reminded of the types of
variables, it's because they don't really know what they're doing.  People
should not use variables without knowing their type...

                                       Brian



#: 33737 S5/C++ Study Group            orig=PgUp next=     prev=
    16-Aug-91  21:13:48                 No: 113 Replies 3
Sb: #33725-Hungarian
Fm: phil hystad 73260,114
To: Brian Richter 76437,736

>...People should not use variables without knowing their type...

Now, I do agree with that statement; however, to be typeless without problems
is bliss.  I program quite a bit in Smalltalk, just for fun. And, Smalltalk
does not have types (in the traditional sense).  Since it is  a pure object
oriented system, and since it is interpretive (late binding), type is not as
important since the actual instructions and logic executed is determined at run
time.  Though this is not as efficient as compiled code but it is nicer knowing
that I don't have to worry about type and everything works hunky-dory anyway.

       phil



#: 33746 S5/C++ Study Group            orig=PgUp next= 118 prev=
    16-Aug-91  23:40:27                 No: 114 One Reply
Sb: #33737-#Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: phil hystad 73260,114 (X)

>[In Smalltalk] type is not as important since the actual instructions and
>logic executed is determined at run time.

No.

>it is nicer knowing that I don't have to worry about type

Well, it's certainly easier to prototype with.

>and everything works hunky-dory anyway.

No (like above).





#: 33752 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  00:59:41                 No: 115 One Reply
Sb: #33746-Hungarian
Fm: phil hystad 73260,114
To: Greg Comeau (ComeauComp) 72331,3421

Greg...

Quit cryptic responses...but, as ever, your comments lose a lot of meaning in
translation (or is that compilation).

       phil



#: 33808 S5/C++ Study Group            orig=PgUp next=     prev=
    18-Aug-91  11:48:51                 No: 116 One Reply
Sb: #33752-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: phil hystad 73260,114

>Quit cryptic responses...but, as ever, your comments lose a lot of meaning in
>translation (or is that compilation).

Sorry, but that's just about the magnitude of the way things gotta be as my
multi-tasker only allow a max of 50 processes.  Anyway, *please* ask me about
anything I've said that doesn't make sense, is cryptic, or is ambiguous etc.



#: 33809 S5/C++ Study Group            orig=PgUp next=     prev=
    18-Aug-91  12:33:12                 No: 117
Sb: #33808-Hungarian
Fm: phil hystad 73260,114
To: Greg Comeau (ComeauComp) 72331,3421

Greg...

My comment on your cryptic-ness was with respect to your terse "yes" and "no"
answers without explanation.  I believe that only God can say "Yes" and "no"
without justification or explanation.  However, so be it for now. I am off to
London in just a few hours and the thread is likely to be terminated (boy, I
still have to see Terminator 2) before I get back.

       phil



#: 33749 S5/C++ Study Group            orig= 113 next=PgDn prev= 114
    17-Aug-91  00:05:56                 No: 118
Sb: #33737-Hungarian
Fm: Ben Sano 72401,2736
To: phil hystad 73260,114 (X)

phil
 >to be typeless without problems is bliss.

BLISS is typeless but Smalltalk is dynamicly typed <g>

--Ben



#: 33763 S5/C++ Study Group            orig= 113 next=     prev=PgUp
    17-Aug-91  11:24:11                 No: 119 Replies 2
Sb: #33737-#Hungarian
Fm: Pete Becker (Borland) 76117,3675
To: phil hystad 73260,114 (X)

Phil,
       Smalltalk has strong type checking.  It just does it later...
       -- Pete (paraphrased from Peter Deutsch)




#: 33765 S5/C++ Study Group            orig=PgUp next=PgDn prev=
    17-Aug-91  11:55:27                 No: 120
Sb: #33763-Hungarian
Fm: phil hystad 73260,114
To: Pete Becker (Borland) 76117,3675

Pete...

Actually, all pure object oriented programming languages have strong type
checking...but, they do take the burden off the programmer and put it in the
binding at runtime.  This was the point I was trying to make though it was not
clear as I re-read my message.

Regarding the Hungarian notation, I used with with Windows programming because
it was so prevalent...but, in my opinion, notation on the identifier name that
declares its type should be un-necessary.

       phil



#: 33839 S5/C++ Study Group            orig= 119 next=     prev=PgUp
    19-Aug-91  14:44:09                 No: 121
Sb: #33763-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Pete Becker (Borland) 76117,3675

>       Smalltalk has strong type checking.  It just does it later...
>       -- Pete (paraphrased from Peter Deutsch)

Well, I'll strongly disagree with that.

Is there any type checking in Smalltalk?  Yes.  Is it strong?  No.



#: 33649 S5/C++ Study Group            orig= 28  next= 125 prev= 93
    15-Aug-91  12:51:49                 No: 122 One Reply
Sb: #33623-Hungarian
Fm: RUSSELL MORE 70242,3546
To: Greg Comeau (ComeauComp) 72331,3421



Hungarian notation drives me nuts and for me personally, destroys the
readability of the code... with ANSI C and a good lint program (or high
warning levels on some compilers) I get all the type restraints I need.



#: 33661 S5/C++ Study Group            orig=PgUp next=     prev=
    15-Aug-91  19:18:34                 No: 123 One Reply
Sb: #33649-Hungarian
Fm: Tom Bernhardt 76646,126
To: RUSSELL MORE 70242,3546

Hungarian is far worse than that.  It is: a. inherently inconsistant (many
dialects/variations due to the vast number of type/attribute combinations). b.
Only minimally useful for very large functions that should not exist anyway. c.
pedantic and insipid (necessitates provision of lots of unimportant/obvious
information at the expense of all-important readability). d. a source of
maintenance and portability problems (why should I change the name of an
identifier when the application dictates that it increase from a short to a
long, i.e., why not use application type prefixes such as numEmployees instead
of CPU/language types).  This is tremendously magnified with the shift to OO
and C++.  Does 'x' in 'void f(short &x)' get a p(pointer) prefix or not? e. an
insult to a country already beleaguered by over forty years of communist
oppression. f. legal proof of psychosis or previously undetected congenital
anencephalism.

Hungarian notation is bad enough in C.  Let's grow up and completely lose in
with C++.



#: 33726 S5/C++ Study Group            orig=PgUp next=     prev=
    16-Aug-91  18:01:37                 No: 124
Sb: #33661-Hungarian
Fm: Brian Richter 76437,736
To: Tom Bernhardt 76646,126

An impressive list of reasons, most of which I would agree with.  (a) is an
excellent reason, especially in C++!  (b) and (c) are good reasons also.
Despite my apparent arguments to the contrary, I'd have to agree with (d). I
don't agree that it's serious within a single program if you have to change the
names as you write it, but as far as maintenance and portability I must agree.
If you have a completed program that you modify in the future you don't want to
go messing with modules that otherwise could remain unedited, just to change
the names.  (BTW, 'x' in 'void f(short &x)' would not get a 'p' prefix; a
reference is not a pointer.)  I agree with (e); if the guy only had a name that
was easier for us to remember, only one guy need be insulted instead of a whole
country <g>.

The only one I'd hesitate to agree with is (f).  After all, people actually
join the Church of Scientology (including one guy that was going to be my
boss!).  From what I hear, even some actually intelligent people.  So if people
can have their minds so twisted around against their will, then certainly a
programmer can be excused for adopting a practice from the leading book on
Windows programming.  I speak from experience on this.  But in C++ HN just
didn't look right!  And everyone's opinion has certainly confirmed this
suspicion...

                                       Brian



#: 33813 S5/C++ Study Group            orig= 28  next=     prev= 122
    18-Aug-91  14:43:17                 No: 125 Replies 2
Sb: #33623-#Hungarian
Fm: Howard L Howell 70703,762
To: Greg Comeau (ComeauComp) 72331,3421

Hello, all,

        Couldn't avoid putting in my two cents worth...
        If you use Hunk... Then you must also use it on functions...
        Therefore, you no longer have complete freedom in function names
because you may obscurely name something in such a way that the function name
overlaps a hugarian declarative....
        Worse, the returned value may be inadvertantly retyped possibly without
correct reconstruction unless your return code (low-level) or your compiler can
detect the return type at run or compile time respectively....
        So... Now you have a dual edit problem... if you rename a variable, you
must be sure that it doesn't overlap a function, and if you rename a function
you must be sure that it doesn't overlap your hungarian naming conventions...
Not to mention possible runtime or compiler overhead.

;-) Les H.




#: 33818 S5/C++ Study Group            orig=PgUp next=PgDn prev=
    18-Aug-91  16:22:13                 No: 126
Sb: #33813-Hungarian
Fm: Brian Richter 76437,736
To: Howard L Howell 70703,762

That was the second reason I didn't like HN.  (The first had to do with overall
crypticness because of separate abbreviations for each class.)  It got carried
over from a C program into C++, and it did strike me as very inconsistent to
use HN for the variables and not for the functions.  And using it for the
functions was absurd because chances were pretty good the names were going to
overlap, or at best be confusing.  To really do it for a function, you'd have
to put in the return value and the types of its arguments, I suppose.  IOW
you'd get one of those C++ mangled function names, which is definitely
something that the programmer should never have to deal with!

Despite this, it definitely surprised me how many people had opinions, and also
that they were all the same.  Thanks for your input...this entire discussion
has been very enlightening...

                                       Brian



#: 33860 S5/C++ Study Group            orig= 125 next=     prev=PgUp
    19-Aug-91  16:30:32                 No: 127
Sb: #33813-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Howard L Howell 70703,762

>If you use Hunk... Then you must also use it on functions...

Yep.
#: 33658 S5/C++ Study Group            orig=ROOT next= 142 prev= 28
    15-Aug-91  16:59:20                 No: 128 Replies 2
Sb: C++ Programming Style
Fm: Brian Richter 76437,736
To: John M. Dlugosz 70007,4657

OK, suppose I did not use Hungarian notation (for the purpose of *this*
thread).  I would think I'd have to be consistent in the sorts of names I chose
for things to avoid confusion.

In my experiments in message "grammar" I commonly ended up using a verb-object
sort of form, with maybe an occasional adjective or adverb thrown in.  But
thanks to the magic of overloaded functions in C++, a function is smart enough
to "know" what type of object you're giving it. Therefore the only thing needed
in the member function's name should generally be the verb.  (An exception to
this would be the set/get family of functions which we already discussed;
they'd have the name of the attribute or data item you're setting or getting.)

Also, you mentioned the idea of starting member variables with an uppercase
letter, as opposed to a set/get function associated with it.  Is this how
member variables can be distinguished from non-member variables?  I would
assume that "ordinary" variables within a member function would generally be
all lowercase (or maybe not, this is just a guess on my part).

And finally, how would one tell constants from variables?  I still put #defines
(rarer in C++; mostly from bits of C code I occasionally reused) in all caps.
Would one want to know, for example, that 'screen_width' is a constant, and not
a variable?

                                       Brian



#: 33666 S5/C++ Study Group            orig=PgUp next= 137 prev=
    15-Aug-91  20:24:12                 No: 129 Replies 2
Sb: #33658-C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Brian Richter 76437,736

Yes, the names are shorter because they are all verb.  Excellent point.

I used initial cap for the private variable, and lower case for the access
function.

   private:
      int Xmax;
   public:
      int xmax() { return Xmax; }

it is just a convienence.  It sure beats synonyms!

I've been using mixed caps or initial caps for Enum values.  I don't have any
DEFINE's except for TRUE and FALSE.

Tell constants from variables?  Well, often times many things are const. The
parameters and variables that are initialized once and used later but never
changed.  I don't mark them special!  constants are very popular.

non-member (global) variables are very rare too.  You can generally recognise
them on sight.  The names can be descriptive too, like main_cursor and
master_update_zone.  Normally such things are static members though.

--John



#: 33717 S5/C++ Study Group            orig=PgUp next= 136 prev=
    16-Aug-91  17:33:32                 No: 130 One Reply
Sb: #33666-C++ Programming Style
Fm: Greg Comeau (ComeauComp) 72331,3421
To: John M. Dlugosz 70007,4657

>   private:
>      int Xmax;
>   public:
>      int xmax() { return Xmax; }

I've been 1/2 ignoring this part of the threads.  So, why would anybody want
to be doing this?  (This question has nothing to do with the X/x naming, but
to what benefit you are seeing in this case in your elaborating into using a
get routine.)



#: 33734 S5/C++ Study Group            orig=PgUp next=     prev=
    16-Aug-91  19:15:43                 No: 131 One Reply
Sb: #33717-C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Greg Comeau (ComeauComp) 72331,3421 (X)

Huh?  that is a classic access function.  You can read the value from outside
the class but not alter it.  It also gives you the flexibily of changing the
implementation and not breaking any code-- all the uses of xmax is a function
call and you can reimplement that function rather than having to track down
every use of the variable and change it to something different.



#: 33744 S5/C++ Study Group            orig=PgUp next=     prev=
    16-Aug-91  23:03:54                 No: 132 One Reply
Sb: #33734-C++ Programming Style
Fm: Greg Comeau (ComeauComp) 72331,3421
To: John M. Dlugosz 70007,4657

>Huh?  that is a classic access function.  You can read the value from outside
>the class but not alter it.  It also gives you the flexibily of changing the
>implementation and not breaking any code-- all the uses of xmax is a function
>call and you can reimplement that function rather than having to track down
>every use of the variable and change it to something different.

Um, I suppose I worded my question wrong.  I've seen the idiom countless
times and realize its reason, but I've always considered the reason more of a
pretext in many cases as I've just seen all this set/get stuff carried way
too far IMO in the name of encapsulation.



#: 33789 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  15:18:51                 No: 133 One Reply
Sb: #33744-C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Greg Comeau (ComeauComp) 72331,3421

Well, it was a trivial example.  In my library, I just make FPen public and let
people set it or read it.  Silly to have access function for that. But the
display resolution, OTOH, is read-only public so I need the function. If C++
had a mechanism for re-specifing access as public but const than it would find
uses here.  Meanwhile, good old inlines will do.

--John



#: 33841 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  14:44:21                 No: 134 One Reply
Sb: #33789-C++ Programming Style
Fm: Greg Comeau (ComeauComp) 72331,3421
To: John M. Dlugosz 70007,4657

>Well, it was a trivial example.  In my library, I just make FPen public and
>let people set it or read it.  Silly to have access function for that. But the
>display resolution, OTOH, is read-only public so I need the function. If C++
>had a mechanism for re-specifing access as public but const than it would find
>uses here.  Meanwhile, good old inlines will do.

That I agree with.  Note though that although I suspect at this point in time
that inline's are and will continue to be the most efficient mechanism, however
note there are 'public: const T &'s that could be used and effortlessly
initialized via constructor member-initializer syntax.



#: 33869 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  17:45:22                 No: 135
Sb: #33841-C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Greg Comeau (ComeauComp) 72331,3421

Yes, I use const members too.  Most people never think of it I'm sure!

But there are cases where I'll want to change things inside and have read only
outside.

Having a public-const ability would just be syntactic sugar.  Easy enough to
add, but that is the problem:  you can do without now, so they won't touch it
for years.

--John



#: 33728 S5/C++ Study Group            orig= 129 next=     prev= 130
    16-Aug-91  18:01:47                 No: 136
Sb: #33666-C++ Programming Style
Fm: Brian Richter 76437,736
To: John M. Dlugosz 70007,4657

I can't help but be reminded of the famous Hofstadter sentence, "This sentence
no verb."

After I wrote my message I started to think about constants and variables. (I
find it sometimes leads to more interesting conversations if I think about my
messages *after* I write them, instead of before. <g>)  I was reminded of good
old MASM (not that I like that syntax!).  At first it had occurred to me that
if you see "mov al,screen_width" you don't know if 'screen_width' is a constant
equate or a variable.  Then I realized that perhaps that's good.  You can later
make 'screen_width' into a variable without changing your code!  So constancy
ought perhaps to be far more temporary than #defines would have had one
believe.  I can think of several constants in one of my programs right now that
may become variables with future enhancements.

Non-member global variables are indeed rare in C++, and the rarer the better.
Actually what I really meant by "non-member" was those temporary variables
inside a member function...

                                       Brian



#: 33683 S5/C++ Study Group            orig= 128 next=     prev= 129
    16-Aug-91  02:03:53                 No: 137 One Reply
Sb: #33658-C++ Programming Style
Fm: Don E. Groves, Jr. 71310,3702
To: Brian Richter 76437,736

Brain,
Would one want to know, for example, that 'screen_width' is a constant, and not
a variable?

  YES, because 'screen_width' should never be a CONSTANT.
    {thats a 'sore spot' waiting to surface.}
Jr..



#: 33727 S5/C++ Study Group            orig=PgUp next=     prev=
    16-Aug-91  18:01:40                 No: 138 One Reply
Sb: #33683-C++ Programming Style
Fm: Brian Richter 76437,736
To: Don E. Groves, Jr. 71310,3702

Sorry, bad example.  Of course you're right.  'screen_height' is the one you'd
want even less to be a constant...

                                       Brian



#: 33890 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  22:30:04                 No: 139 Replies 2
Sb: #33727-C++ Programming Style
Fm: Don E. Groves, Jr. 71310,3702
To: Brian Richter 76437,736

Brian,
  Didn't mean to sound so Turse about.
    { assuming screen Width a CONSTANT }
Note: Even QuarterDeck Office System did it in DESQVIEW.
Which is HARD-CODED to an 80 character wide screen.
   Bring it up in a Oversize Screen setup and the main menu winds up all out of
shape. { somebody tried to save a few bits of code <G> }
Jr..



#: 33898 S5/C++ Study Group            orig=PgUp next=PgDn prev=
    20-Aug-91  00:26:05                 No: 140
Sb: #33890-C++ Programming Style
Fm: John M. Dlugosz 70007,4657
To: Don E. Groves, Jr. 71310,3702

Mine did not work at all if the screen was in 90 col mode (herc plus).  Have
not figured that one out.  I got a highlight bar but no visible text!

putting it in 90 col mode while running makes the monitor desync when changing
screens.

A while back, discussion turned to the 80 col hardcode in Borland's IDE. The
reason given was "speed".  We figured out that the fastest way to do screen
lookups was with an array of line offsets, which allows variable widths!  So
much for that excuse.  Meanwhile, I used variable col on my first code on a
4.77 Mhz PC and did not find it too slow (it _is_ a hundred clocks more to do a
multiply, but I never thought about it).  So I did not like the answer anyway.

--John



#: 33913 S5/C++ Study Group            orig= 139 next=     prev=PgUp
    20-Aug-91  11:54:03                 No: 141
Sb: #33890-C++ Programming Style
Fm: Brian Richter 76437,736
To: Don E. Groves, Jr. 71310,3702

I did it too, in my last project, but there was good reason then.  The entire
screen layout was designed around 80 columns.  By definition, things had to be
certain widths, so there was no advantage in having more columns. Screen height
is the thing you *really* don't want to be a constant; it's really common to
want to change the height, I think...

                                       Brian



#: 33772 S5/C++ Study Group            orig=ROOT next=     prev= 128
    17-Aug-91  13:53:43                 No: 142 One Reply
Sb: #Hungarian
Fm: Brian Richter 76437,736
To: All

Right from the horse's mouth...

*******************************

That's kind of an odd expression, when you think about it.  I just used it here
as a sort of cheap attention-getting device.  Anyway, during this discussion, I
thought, "Gee, if only I could talk to the creator of this notation and find
out why *he* likes it."  As it turned out, someone already beat me to it, and
the result was sitting on my bookshelves in a book called "Programmers at
Work".  The very first chapter was an interview with Charles Simonyi, and he's
the guy.

Essentially his argument was that the names are the greatest bulk of a program,
so that's the part to improve.  To do so, the properties of a variable actually
become part of the name.  (It surprised me a bit here that he did not say the
"type", but apparently variable types are not really the essence of HN.)  Then
he argues that readability as far as reading the names out loud is not
important because you don't go up to a podium and read a program.  He says the
association between the name and the properties is important in increasing
comprehension.  Also, apparently "Hungarian" is a joke; people found the
notation cryptic and said it must be Hungarian.  And I had thought it was
because people couldn't remember his name...


[More]








#: 33773 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  13:53:49                 No: 143 Replies 2
Sb: #33772-Hungarian
Fm: Brian Richter 76437,736
To: Brian Richter 76437,736

[Continued]

Anyway, the book gave an example of "Hungarian" code taken from MS Word. The
name "vbchrMac" is translated as follows:

The variable is global (v), current maximum pointing one beyond the last
element (Mac) based pointer to a group (b) of chr structures. The name chr has
further meaning:  character run, which is specific to Word.

For those of you who are "use-mention" fanatics, I just copied that paragraph
right out of the book, so don't blame me for the lack of appropriate quotes.

In any case, this is more extreme than anything I've seen, even in Windows. And
honestly, I don't really care for it.  It still doesn't tell me what group of
"chr" structures it points at or give me a hint as to why I need such a
variable in the first place.  It could even be that this is what some of you
were thinking of as HN, and in that case I'd have to agree...

                                       Brian



#: 33790 S5/C++ Study Group            orig=PgUp next= 150 prev=
    17-Aug-91  16:08:21                 No: 144 One Reply
Sb: #33773-#Hungarian
Fm: Rudyard Merriam 76234,2561
To: Brian Richter 76437,736 (X)

Brian

I tried to creat a name that I would use for that "vbchrMac" and I couldn't
even figure enough of what it did!. The best I got was "Cur...Ptr" or maybe
"Nxt...Ptr" but whatever is supposed to be where the "..." is totally eluded
me. Maybe I'd add "Gbl" to the fron but I don't usually have global vars so
that isn't normally a critical distinction. But I really find 'v' to be
mnemonic for global <s>.

After another look I guess the name would be "NxtChRunBPtr".

Rud




#: 33795 S5/C++ Study Group            orig=PgUp next=     prev=
    17-Aug-91  17:32:45                 No: 145 Replies 2
Sb: #33790-Hungarian
Fm: Brian Richter 76437,736
To: Rudyard Merriam 76234,2561

Looking at the code fragment on that page that uses it is still no help in
figuring out what that variable does.  Although there's a lot of information in
that name, I think something's still missing.  Your name makes more sense to
me.  I can just look at it and say to myself "next character run based
pointer".  Despite his point that you don't read code aloud, with HN you have
to translate it to yourself.  Given "vbchrMac" and that I knew the code, I'd
look at it and say, "uh, global based character run mac" (assuming that you
further remember what "Mac" means).  As I scan the code, I have to keep
performing this translation process every time I read it.  So to me, the code
is very hard to read.

Maybe to the programmer it's less confusing, but code will generally have to be
read by someone else too.

                                       Brian



#: 33816 S5/C++ Study Group            orig=PgUp next= 148 prev=
    18-Aug-91  15:27:56                 No: 146 One Reply
Sb: #33795-#Hungarian
Fm: Rudyard Merriam 76234,2561
To: Brian Richter 76437,736 (X)

Brian

Reading that "vbchrMac" reminds me of working in Fortran and later in Forth.
Fortran because it had the 6 char limit on variable names so you wound up with
a lot of "ICN" for an "integer customer number". Then the Forthians tended to
be cryptic with their word names.

Rud




#: 33819 S5/C++ Study Group            orig=PgUp next=     prev=
    18-Aug-91  16:22:18                 No: 147
Sb: #33816-Hungarian
Fm: Brian Richter 76437,736
To: Rudyard Merriam 76234,2561

I remember FORTRAN.  Never used Forth.  It reminds me of a couple of recent
assembly language programs I had to upgrade.  They were done on an ancient
development system that only allowed 6 character symbol names.  As a result
many of them were unavoidable cryptic; most were acronyms.  We ported the
source code over to a PC, and got an assembler that supported 32-character
names.  Once I puzzled through it to figure out what they did, I actually found
it worthwhile to edit all the modules to rename the variables and subroutines
to reflect what they really did.  This was a lot of work, but the change proved
to be simple once that was done, and it actually worked the first time!

                                       Brian



#: 33851 S5/C++ Study Group            orig= 145 next=     prev= 146
    19-Aug-91  14:45:03                 No: 148 One Reply
Sb: #33795-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736

Besides seeing that its hard to read, it's not clear to me why chr is
lowercase?  What if chr had encodings in it?  For instance, what if chr was
called bchr?  What's he limited now is even the though behind the "normal" part
of the name.  And yes, although he's right about not uttering program's at
podium's, he is wrong in the sense that it is often a consideration for the
telephone, and furthermore, unless one is not intimate with a given name, one
most certain has to stop to figure it out (since of course, figuring it out
*is* part of the premise of HN).



#: 33874 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  17:51:18                 No: 149
Sb: #33851-Hungarian
Fm: Brian Richter 76437,736
To: Greg Comeau (ComeauComp) 72331,3421

I think he's wrong about reading a name, because even when I read my own code I
do read it to myself, in a sense.  Certainly you do sometimes say a name to
yourself as you think of it, and HN deprives you of the ability to do that.
And you do certainly talk about it with other people.

As I read HN, I have to figure things out each time I read them...

                                       Brian



#: 33850 S5/C++ Study Group            orig= 143 next=     prev= 144
    19-Aug-91  14:44:57                 No: 150 One Reply
Sb: #33773-Hungarian
Fm: Greg Comeau (ComeauComp) 72331,3421
To: Brian Richter 76437,736

>vbchrMac

Phew.  Even with the verbiage, I don't understand what the thing does.

I hope this example was significant enough to be demonstrative enough
to signify the end of HN!!! (and the end of the thread ;-})



#: 33875 S5/C++ Study Group            orig=PgUp next=     prev=
    19-Aug-91  17:51:24                 No: 151
Sb: #33850-Hungarian
Fm: Brian Richter 76437,736
To: Greg Comeau (ComeauComp) 72331,3421

vbchrMac...

Even with the code fragment in front of me, I don't understand what it does!

Even I, who started this thing, believe we've had plenty of discussion on this.
So I was in fact going to recommend we end this thing.  Except that I would
still be curious to see that thread with Petzold if anybody can retrieve it...

As a final note, I have nearly completed a Hungarianectomy on the program I'm
working on.  It's a sizable program but the process is easy (though a bit
tedious).  Seeing the identical code in HN and non-HN forms is an excellent
test.  And so far non-HN is winning (but of course you knew that would happen).
It's almost startling to see pieces of code that looked messy before suddenly
appear elegant and simple.

And BTW, thanks to all youse other guys who responded.  You have saved the
world from quite a few potential HN programs!

                                       Brian